Preserve GVFS locks when commands collide with aliases - #2139

Problem and Context

Git runs the pre-command hook with the name of a built-in command, or with git-<name> when it will run a program or expand an alias.
The hook used a static command inventory and an alias.<name> config query to skip the GVFS lock for aliases.
The inventory omits built-ins such as stash and cannot cover custom programs.
A same-name alias can therefore skip the lock even when Git runs the real command.
Nested Git processes from external programs inherit hook suppression, so they cannot supply the missing lock.
The read-only exemption list also applies to git-<name>, so a program such as git-LOG on PATH runs without a lock.

The config query also misses the [alias "<name>"] command form.
Git 2.56.0.vfs.0.4 does not run post-command for git-<name> before it expands an alias, although its source calls the hook on that path.
So when the hook keeps an outer lock on a genuine alias, the first locking command in that alias waits for its own parent until the user cancels.
The hook must therefore predict Git's choice between a program and an alias.

Ordinary git stash already takes the lock.
This repair addresses command-resolution collisions, not general stash reliability or which built-ins are read-only.

Changes

• Decide from the raw hook argument. Apply the read-only exemption list only to built-ins, and to Git's git-submodule and git-web--browse programs.
• Remove the static command inventory.
• For git-<name>, look for a program as Git for Windows does in path_lookup and lookup_prog: raw PATH entries, "<entry>\git-<name>.exe" with and without .exe, and GetFileAttributesW, which fails for the same files as _waccess. If Git will run a program, take the lock.
• Otherwise, read the alias config keys with the parent git.exe (git config --name-only --get-regexp ^alias\.). Suppress recursive command hooks, decode the output as UTF-8, and retry once on a transient config access error. Match the keys as Git does: split each key at its last dot, as parse_config_key does. alias.<name>, an empty subsection (alias..<name>), and other dotted names such as alias..review.foo match for any ASCII case. alias.<name>.command matches only the exact name, also when the name starts with a dot. Skip the outer lock only when a key matches.
• Stop the command with an error when the hook cannot tell what Git will run: the alias keys or the parent git.exe path cannot be read, or a PATH candidate does not fit Git's MAX_PATH buffer.
• In post-command for git-<name>, release the lock only when the parent Git process owns it. Do not look up aliases or PATH again. If the mount is not reachable, return without an error.
• Use availability-only locking only for the built-in status, not for a git-status program. Move this check into GitCommandLock, which the unit tests compile.
• Tell the user to run gvfs status in the new lock-ownership errors.
• Document how aliases interact with command locks.
• Add unit tests for built-in and external names, programs found on PATH with Git's path rules, PATH candidates that do not fit Git's buffer, the case rules of each alias form, dot-prefixed subsections, failed alias reads, the read-only list for git-<name>, the availability-only status check, and lock-ownership responses.
• Add functional tests that run real Git with a lock holder for built-in and external collisions, both alias forms, both dot-prefixed subsection forms, an alias from a config file, a subsection alias with capital letters, nested aliases, command spellings, directories on PATH, and invalid PATH entries. The tests check that a script runs when it collides with an alias.
• Add a functional test that calls both hooks with a live Git PID and deletes the external program between the calls. The test asserts release before the Git process exits.
• Add a functional test that calls pre-command with a live Git PID while the global config is locked. The test asserts that the hook stops the command and that the lock stays free.
• Add a functional test that runs GVFS.Hooks.exe in a folder that has a .gvfs folder but no mount. The test asserts that post-command for git-<name> exits without output, and that post-command for status reports the missing mount.

Validation

The PR compares the time of whole git commands in a mounted dev enlistment, with the hook from master (0889bc6) and the hook from this PR. Both hooks are Release builds with native AOT, as in a release. A temporary test changed the hook path in .git\hooks\*.hooks in each round, and ran each command 60 times with each hook after one warm-up round. The machine has a Snapdragon X Elite (Windows on ARM64, x64 hooks), Git 2.56.0.vfs.0.4, and 31 PATH entries. The table shows the median time in milliseconds.

Built-in commands show no measurable change. An alias is about 10 ms slower, because the hook checks PATH before it reads the alias keys. An external program is about 90 ms faster, and a built-in that an alias shadows is about 170 ms faster. In both cases, master started git config for each command that was not in its command list.

Known gaps and deliberate decisions

• Git does not run post-command before alias fallback. If Git ran that callback, the hook could lock whenever it is unsure and release the lock before the alias runs. Until then, a program that Git finds but cannot start causes the alias deadlock. Examples are a program that disappears after the hook checks it, and a script whose #! interpreter does not exist. Cancel the command to end the wait.
• The alias rules follow current Git. Git versions without [alias "<name>"] command treat that key as the dotted alias <name>.command. The hook matches the newer rule.
• Some commands stop with an error. If the hook cannot read the alias config, or a PATH entry is too long for Git's path buffer, it stops the command instead of guessing.
• Custom git-submodule and git-web--browse keep their exemptions. A custom GIT_EXEC_PATH can replace these Git programs. The hook does not check which program Git selects for them.
• The hook adds work for each git-<name> command. It checks PATH, and it starts git config when no program exists.
• Hook diagnostics include the failing operation and native error details. They do not create a separate durable log.